1. Field of the Invention
The present invention generally relates to computer systems, and more particularly to a method for mapping the shared memory of a multiprocessing computer system when it is simulated on another multiprocessing computing system.
2. Description of the Related Art
A computing system includes several parts, including the processors, the memory and the input/output devices. It is often necessary to emulate the behavior of one computing system on another.
One of the principal reasons for emulation is to enable programs written for a system (e.g., a “target computing system”), to perform with the same results on another system (e.g., a “host computing system”). Several techniques have been described to emulate the instruction set of one processor using the instruction set of another processor (e.g., SIMOS as disclosed by Stephen A. Herrod, “Using Complete Machine Simulation to Understand Computer System Behavior,” Ph.D. Thesis, Stanford University, February 1998; or MIMIC as disclosed in Cathy May, “Mimic: A Fast System/370 Simulator”, Proceedings of the Object Oriented Programming Systems Languages and Applications Conference, (OOPSLA), Orlando, Oct. 4-8, 1987, Special Issue of Sigplan Notices, vol. 22, No. 12, December 1987, vol. 22, No. 7, June 24).
To perform the emulation faithfully, it is necessary also to emulate the behavior of memory in such a system. Typically, the behavior includes more than reading and writing locations in memory with program-specified addresses.
More particularly, when virtual memory is implemented on the target system, as is usually the case, an access to a memory location may involve verifying whether the requesting task has the right to perform the access operation. It may also involve bringing in the page containing the requested location to memory, if it is not already in memory.
Such functions are typically performed as illustrated in the system 100 shown in FIG. 1, where a calculated operand address is input, as a target virtual memory address, into a target page mapping table 110.
Thus, in FIG. 1, the page containing an addressed location is checked in the table 110, to see whether (a) it is already in memory (e.g., target real memory 120), (b) whether it permits the access desired, and (c) what physical memory location corresponds to the desired page. It is noted again that each of these operations is performed in the actual hardware of the target system.
To make such an access efficient, these checks are performed in hardware in the emulating machine, and often simultaneously with the actual memory access, with the results of the access discarded if access is denied. The output of the target real memory 120 is an operand value which may correspond to a LOAD, etc. (It is noted a STORE would go the other way through the host).
Typically, the host computing system also provides hardware to facilitate such virtual addressing. Implementations like those disclosed in U.S. Pat. No. 6,075,937, to Scalzi et al., interpret target accesses in terms of primitives supported by the host virtual addressing hardware. This is shown in the system 200 of FIG. 2 which utilizes a simulated page mapping table 210 and a host real memory 220.
The mapping of virtual addresses to real addresses in host real memory 220 done through the page mapping table 210 is unique for each virtual address space (often associated with a “process”) on the target system.
It is noted that the simulated page mapping table 210 differs from the target page mapping table 110 in that the operating system has page mapping tables therein which map virtual pages to real pages of the host real memory. However, in FIG. 2, this will not be operable (e.g., not work) since the real memory must address the host real memory, not the target real memory. Hence, the map must include another field which indicates where the real memory is which is being mapped into the host real memory.
If the host system also implements a virtual memory and if the allowed virtual address space for each host process is at least as large as the address space allowed on the target, then emulation can be performed at the process level as shown in the structure 300 of FIG. 3, having a target-to-host virtual address mapper 310, a host page mapping table 320, and a host real memory 330.
In the scheme of FIG. 3, a target virtual address space is mapped to a host virtual address space by mapper 310, which is then converted to the host real address space using the host's page mapping table mechanisms 320.
Thus, in FIG. 3, in the front end, instead of having a simulated page mapping table (e.g., table 210 in FIG. 2), the target-to-host virtual address mapper 310 is provided, so that the target virtual address can be converted to a host virtual address, and then uses the operating system of the host to do the rest of the mapping.
Basically, the scheme behind FIG. 3 recognizes that the functional blocks of FIG. 2 cannot be performed on an operating system of the host. Hence, FIG. 3 aims to take a target virtual memory address and convert it into something (e.g., a host virtual memory address) that can be used by the operating system which is running on the host system. The operating system running on the host has its own page mapping tables which can recognize and understand only virtual memory addresses in its environment (e.g., the host virtual memory addresses). Thus, once the host virtual memory addresses are obtained, the rest of the mapping can be performed in the host.
However, both of these schemes prove inadequate in an emulation environment such as that described in the above-mentioned U.S. patent application Ser. No. 10/244,414, filed concurrently herewith, to Altman et al., entitled “METHOD AND SYSTEM FOR MULTIPROCESSOR EMULATION ON A MULTIPROCESSOR HOST SYSTEM”. In such an environment, the simulation of a processor in the target multiprocessing system is not directly performed by a unique processor in the host multiprocessing system.
Instead, the tasks of emulating the processors are pooled along with other auxiliary tasks needed on the host, and a scheduler on the host allocates these tasks to available processors. An advantage of this scheme is the possibility of emulating a system which may have more processors than the processors available on the host.
The scheme disclosed in U.S. Pat. No. 6,075,937, to Scalzi et al. requires that each target processor be mapped to a host processor. That is, such a system requires a one-to-one correspondence, and hence is not well-suited for such an emulation.
The virtual mapping scheme is a possible candidate, except that it requires that emulation software know about the partitioning of tasks in the target system into processes. This may often not be possible unless the emulation system understands the system software being emulated.
That is, it must be known exactly what is happening in the operating system running on the target (guest) to make the scheme of FIG. 3 work, since the page mapping table of the target (guest) will be replayed to target-to-host virtual address mapper 310, etc. However, this rarely happens because in performing a system emulation of a system, one seldom has control over the software which is running.
Moreover, it is not directly possible to map a 64-bit virtual addressing space of the target, for example, to a 32-bit virtual addressing space of the host. As mentioned earlier, memory must often be reserved also for other functions associated with the emulation, and hence such an emulation may be difficult even in a 64-bit virtual address space for the host.
Therefore, it is desirable to find a solution to the memory mapping problem where the emulation environment does not have a strict correspondence between the target processor being emulated and the host processor that reproduces its behavior (e.g., in a multiprocessing environment where there is a many-to-many mapping), and where the emulation software is cognizant of the page table mapping of the target system, but not the nature of the tasks executing on the target system (e.g., where there is not actual, strict control over the software running on the target).
Prior to the present invention, no such solution has been recognized, let alone developed.